Conventional browsers such as Microsoft Internet Explorer and Netscape Navigator have “Back” and “Forward” buttons. The function of these buttons in different browsers is essentially the same. When a user navigates from a first page displayed in the browser to a second one, for example using a hyperlink, the browser registers the navigation in its history. If the user clicks the Back button while the second page is displayed, the browser “steps back” in its history and instead displays a cached version of the first page. At that time, the user can click the Forward button to resubmit the request for the second page. This functionality usually is sufficient for displaying pages from a stateless application in the browser. For stateful applications, in contrast, there may be problems. Some users wrongly assume that they can undo or redo changes in the application by clicking the Back and Forward buttons.
On the contrary, Back and Forward actions by the user are usually not communicated to the server at all. If the first page was obtained (from the server) using the GET command as specified in the Hypertext Transfer Protocol (“HTTP”), then the Back button click causes the browser to display the cached version of the first page without sending any request to the server. The server is therefore not “aware” that this navigation takes place in the browser. This may lead to problems. For example, some or all information on the first page may have become invalid in the meantime. This is because the browser's navigation back to the cached version of the first page does not undo any action that the server took in the process of changing from the first page to the second page. In other words, if the first page corresponds to the server application having a first state and the second page corresponds to a second state, then clicking the Back button does not change the application back to the first state.
Another HTTP command, POST, may cause similar problems. This command may not permit the use of the Back button at all. That is, although the Back button appears active in the browser, clicking it may result in an error message. Accordingly, the Back button does not accomplish what the user may have intended by clicking the Back button—to undo the last taken step. Alternatively, clicking the Back button after a POST request may prompt the browser to confirm whether the user wishes to have the original request for the first page resubmitted to the server. But because the server did not revert the application back to its previous state, the original request may now be ill-defined or nonsensical to the server. The above described problems are not limited to the Back button. Also the Forward button may lead to unexpected events, for example if it causes a previous request to the server to be resubmitted when the server application is in a different state than when the request was originally sent.
In response to problems such as these, it has been proposed that at least the Back button in the browser be deactivated. However, conventional browsers do not allow the Back button to be deactivated. Others have implemented special “Back” and “Forward” buttons in the application page(s) that may allow the user to undo or redo actions. One problem with this approach is that the browser's Back and Forward buttons remain active. Because browsers have become so widely used, users are likely to click on the browser buttons out of habit instead of on the designated buttons.
Yet another attempted approach is to prevent the browser from caching a page, thereby forcing the browser to request the page anew from the server. One disadvantage with this approach is that it only works with the GET request. Another is that it does not allow the server to control what happens on the browser when the user clicks the Back or Forward button.